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The Software Productivity Consortium is sponsored by 14 aerospace companies as a 
developer of software engineering methods and tools. Software reuse and prototyping are 
currently the major emphasis areas. The Methodology and Measurement Project in the 
Software Technology Exploration Division has developed some concepts for reuse which 
they intend to develop into a synthesis process. They have identified two approaches to 
software reuse: opportunistic and systematic. The assumptions underlying the systematic 
approach, phrased as hypotheses, are the following: the redevelopment hypothesis, i.e., 

software developers solve the same problems repeatedly; the oracle hypothesis, i.e., develop- 
ers are able to predict variations from one redevelopment to others; and the organizational 
hypothesis, i.e., software must be organized according to behavior and structure to take 
advantage of the predictions that the developers make. The conceptual basis for reuse 
includes: program families, information hiding, abstract interfaces, uses and information 
hiding hierarchies, and process structure. The primary reusable software characteristics arc 
black-box descriptions, structural descriptions, and composition and decomposition based 
on program families. A good methodology has the following properties: 

1. It answers the following key questions at any 

point in the development process: 

a. What should I do next? 

b. What output do I produce? 

c. What input and resources do I need to produce it? 

d. How do I know when I’m done? 

2. It is based on a clear set of principles 

3. It leads to quantifiable improvements in productivity and quality 

4. It is useful to engineers 

5. It promotes reuse 

6. It supports a sound business approach 

Automated support can be provided for systematic reuse, and the Consortium is developing a 
prototype reuse library and guidebook. The software synthesis process that the Consortium is 
aiming toward includes modeling, refinement, prototyping, reuse, assessment, and new con- 
struction. A number of key issues were also discussed. 
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TOPICS 


• Concepts 

- Systematic vs Opportunistic Reuse 

- Assumptions Underlying Systematic Reuse 

- Underlying Principles 

• Methodological Considerations 

• Automated Support 

- Reusable Software Libraries 

• Current Consortium Practice 

• Direction 

- Synthesis 


ORGANIZING SOFTWARE FOR REUSE 

• Opportunistic Reuse - The Garage Sale Approach 

- Many individual parts 

- Search for part with desired behavior 
— Attributes + Behavioral Description 

• Systematic Reuse - Systems Approach 

- Collections of related parts 

- Search for system that meets requirements 

— Attributes + Behavioral Description + Relationships + 
Classification 
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ASSUMPTIONS 


• Redevelopment Hypothesis 

- Software developers solve same problems repeatedly 

- Solutions are captured as systems 

- Variations 

— Devices 
— Algorithms 
— Platforms 
— Functionality 

• Oracle Hypothesis 

- Developer must be able to predict changes 


• Organizational Hypothesis 

- Organize according to behavior and structure 

- Expose structures that make changeable decisions 
apparent 

- Identify common characteristics 
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DESIRABLE SOFTWARE CHARACTERISTICS 


• Black-box description 

- Behavioral approach 

• Structural Descriptions 

• Composition and decomposition based on collections of parts 


CONCEPTUAL BASIS 

• Program Families 

- Characterize commonalities first 

• Information Hiding 

- Encapsulate changeable decisions 

• Abstract Interfaces 

- Behavioral descriptions of modules 

• Uses Hierarchy 

- Protect subsettability 

- Explicit decisions about dependencies 

• Information Hiding Hierarchy 

- Roadmap for change 

• Process Structure 

- Performance assessment 

- Reconfigurability 


70 



REUSABLE SOFTWARE CHARACTERISTICS 


• Black-Box Descriptions 

- Behavioral approach, e.g., based on A-7 module 
descriptions 

• Structural Descriptions 

- Hierarchical views, based on information hiding and uses 
hierarchies 


• Composition and Decomposition Based On Program 
Families 

- Families described structurally 

- Components of families described behaviorally 

- Many shared subfamilies 
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METHODOLOGICAL CONSIDERATIONS 


DEFINITIONS 


PROCESS 

- Set of activities used to produce and maintain software 
METHODOLOGY: Answers to the Questions: 

- What do I do next? 

- What input do I need to do it? 

- What output do I produce? 

- What resources do I need to produce it? 

ATTRIBUTES OF A GOOD METHODOLOGY 

• Answers the key questions 

What do I do next? 

What input do I need to do it? 

What output do I produce? 

- What resources do I need to produce it? 

• Based on a clear set of principles 

Information hiding, hierarchical structuring, etc. 

• Leads to improvements in productivity and quality 

Measurable 

• Useful to engineers 

• Promotes reuse 

• Supports sound business approach 

• Can be adopted incrementally 



OBJECTS SUPPORTING SYSTEMATIC REUSE 


• Requirements Specification 

• Module Guide 1 

. Abstract Interface Specification 

• Allowed-to-Use Hierarchy 

• Module Internal Documentation ► 

• Uses Hierarchy 

• Process Structure 

• Potential Family Members 

J 

• Code 

• Tests 


Design 


SOFTWARE EVOLUTION PROCESS 


Developers maintain collections of program families 

Requirements are identified using families that support: 

simulation, prototyping, modeling, other forms of analysis, 

- production of specifications. 

Given the requirements for a new system: 

the collections are searched for a family with a member that meets the 
requirements, 

modules of the family are adapted and assembled to produce the new 
member, 

if no such family exists, a new family is created (rare). 
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AUTOMATED SUPPORT FOR SYSTEMATIC REUSE 

• Reuse Library 

- Repository for collections of families 

• Adaptation Analysis 

- Tracing the effects of change 

• Construction of specifications 

- Editor, browser 

- Design representation 

• Adaptation Mechanism 

- Parameterized module/subset generation 
— Generic, macros 

• Modeling 

- Performance analysis 

• Composition 

- System generation 

REUSE LIBRARIES 

• Storage of Life Cycle Objects (LCOs) and their Descriptions 

- Requirements 

- Module Guide 

- Module Interface Specification 

- Code 


• Search Mechanisms 

- By Attribute 

— Language, version, author, producing tool, etc. 

- By LCO type 

- By Relation 

— Hierarchy traversal (uses, information hiding, 
composition, etc.) 

- By Classification 

• Object descriptions 

• Population 
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CURRENT CONSORTIUM PRACTICE 


• Guidebook 

- Management and Technical Volumes 

• Reuse Library Prototype 
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Software Technology Exploration Guidebook 
Volume 1: Management Guidebook 

Table of Contents 

August 26, 1988 

I. [lie Software Technology Exploration Division May 27, 1988 

II. STIC Organization and Strategic Plan for 1988 May 26, 1988 

III. Consortium Configuration Management (No. 700-1) May 24, 1988 

IV. Configuration Management Guidelines for STE May 30, 1988 

V Guidelines for Document Preparation and Distribution May 26, 1988 

V I. Guidelines for Writing Project Proposals May 26, 1988 

VII. Guidelines for Writing Project Reports May 26, 1988 

VIII. Guidelines for WViting Risk Reports August 15, 1988 

IX. University Grant Programs May 27, 1988 

X. Division Organization Chart September 1, 1988 

XI. Guidelines for Writing Project Activity Reports August 15, 1988 

Software Technology Exploration Guidebook 
Volume 2: Technical Guidebook 

Table of Contents 

August 31, 1988 

XII How to Read This Guidebook 

XIII. Principles and Concepts 

XIV. Process and Products 

XV. Verification of Work Products 

XVI. Techniques 

XVII. Measuring Process and Products 
XVIII. Examples 
XIX Glossary 
XX. Bibliography 


August 31, 1988 
July 19, 1988 
August 31, 1988 
July 19, 1988 
August 31, 1988 
July 18, 1988 
August 31, 1988 
June 29, 1988 
July 1, 1988 
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DIRECTION 


SYNTHESIS: A PROCESS THAT RELIES ON THE 

PRODUCTION OF SOFTWARE FROM 
MODELS SPECIFICALLY DESIGNED 
FOR REUSE 


RELATIONSHIPS AMONG MODELS 


Application Models Design Models Executable Code 



Other Work Products 
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ASPECTS OF SYNTHESIS 


MODELLING 

- APPLICATION 

- DESIGN 

- IMPLEMENTATION 

REFINEMENT 

- SUCCESSIVE APPROXIMATION OF PROBLEM 

- SUCCESSIVE APPROXIMATION OF SOLUTION 
PROTOTYPING 

- REFINEMENT THROUGH ISSUE RESOLUTION 

REUSE 

- STANDARDIZED ENGINEERING SOLUTIONS 

- SOLUTIONS REPRESENTED IN TERMS OF REUSABLE PARTS 

- COMPOSITION OF NEW SYSTEMS FROM EXISTING, ADAPTED, 
AND NEW PARTS 

ASSESSMENT 

- QUANTIFICATION OF APPROXIMATION 


NEW CONSTRUCTION 



STEPS IN THE SYNTHESIS PROCESS 


• SPECIFY REQUIREMENTS 

- DIRECTLY, IN TERMS OF PRE-DEFINED DOMAIN 
VOCABULARY 

- ANALOGOUSLY, IN TERMS OF DIFFERENCES BETWEEN NEW 
NEEDS AND EXISTING SYSTEMS 

• MAKE APPLICATION MODEL 

- MODEL CONSTRUCTION 

- MODEL ASSESSMENT 

• MAKE DESIGN MODEL 

- SELECTION OF CANONICAL DESIGN 

- ADAPTATION OF CANONICAL DESIGN 

- INVENTION OF NEW DESIGN 

- ASSESSMENT OF DESIGN 

• IMPLEMENT 

- COMPLETION OF NEW AND ADAPTED PARTS 

- COMPOSITION OF PARTS INTO PROTOTYPES/PRODUCTS 

- VERIFICATION 
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SUPPORTING ELEMENTS 


REPOSITORIES 

- REUSE LIBRARY 

- PROJECT LIBRARY 
REPRESENTATION TECHNOLOGY 

- USER INTERFACE 

- SPECIFICATIONS FOR MODELS, DESIGNS, CODE PRODUCTION 

METHODOLOGY 

- PROCESS MODEL 

- NATURE OF PARTS AND RELATIONS 

- MANAGEMENT OF PROCESS 

ARCHITECTURE OF TOOLSETS 


TOOLSET INTEGRATION 



KEY ISSUES 


• HOW TO DO DOMAIN ANALYSIS 

- SYSTEMATIC APPROACH 

- APPLICATION MODELLING 

- RE-ENGINEERING 

• NOTATIONS AND MECHANISMS FOR MAPPING FROM 
APPLICATION MODEL TO SOFTWARE DESIGN 

- WHAT NOTATIONS? 

- PIOW MANY INTERMEDIATE LEVELS? 

• HOW TO REPRESENT DESIGNS: PARTS AND THEIR RELATIONS 

- WHAT NOTATIONS? 

- STORAGE, RETRIEVAL, AND SEARCH 

- RE-ENGINEERING 

• PIOW TO ADAPT, COMPOSE, AND VERIFY PARTS 

- DESIGN PARTS 

- CODE PARTS 
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KEY ISSUES (CONC) 


HOW TO ASSESS DESIGNS AND CODE 

- PERFORMANCE 

- FUNCTION 

- DEPENDABILITY 

HOW TO PRODUCE CODE 

- PROTOTYPE 

- PRODUCTION 

HOW SHOULD THE ENGINEERS INTERACT IN THE PROCESS? 

- INTERFACE 

- PROCESSING STEPS 

- UNDERSTANDING OF CONTEXT 

HOW SHOULD THE PROCESS BE MANAGED? 

HOW SHOULD THE EFFECTIVENESS BE MEASURED? 

- CURRENT STATE 


GUIDE TO IMPROVEMENT 


PROJECTS 


• METHODOLOGY, MEASUREMENT, AND MANAGEMENT 

• DESIGN REPRESENTATION, MAPPING FROM APPLICATION 
MODELS, AND COMPOSITION 

. DOMAIN ANALYSIS 

• REPOSITORIES 

• ASSESSMENT 

• VERIFICATION 

• ADAPTATION 

. INTERACTION WITH THE ENGINEERS 

PROGRAM FAMILIES 

HARDWARE ANALOGIES — THE IBM 360, DEC PDP-11 

• Families of computers 

- Same instruction set architecture 
(Behavioral description) 

- Different implementations 

- Same operating system 
(Different versions) 

• Program family: A set of programs is a program family if 
the programs have so much in common that it pays to study 
their common characteristics before investigating the special 
properties of individual programs. 
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EXAMPLE FAMILY 

CLASSIFICATION 

Tool Families 

Process Support 

Technology 

Describing 

Data Storage & Retrieval 

Composing & Decomposing 

User Interface 

Assessing 

Data Transformation 

Retaining 

Configuration 

Application Families 

Avionics 

Communications 

A-6 

Control Systems 

A-7 

Speech Processing 

727 
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A-7 NAVIGATION FAMILY 


SINS alignment 




INFORMATION HIDING 


• A decision that is likely to change should be encapsulated in a module 

Changeable decision is the secret 

— data structures 

— algorithms 

— device characteristics 
Basis for Ada packages 

• Module: An information hiding module is a work assignment 

An information hiding module is a black-box 

An information hiding module is a set of programs and shared data 
An information hiding module is a finite state machine 

• Interface: An interface between two modules is the set of assumptions that the 

programmer of one module may make about the other module 

• Abstract Interface: An interface that represents many possible actual interfaces 


HIERARCHIES AND STRUCTURE 

• Module Hierarchy 

Parts: Modules 

Relation: Subsecret B is a submodule of A if B’s 

secret is a subsecret of A’s secret 

• Uses Hierarchy 

Parts: Programs 

Relation: Uses A uses B if A requires the presence of B 

• Process Structure 

Parts: Processes 

Relation: Awaits A awaits B if A cannot progress until B 

progresses 
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A- 7 MODULE STRUCTURE 


HARDWARE-HIDING MODULE DECOMPOSITION 1 

EXTENDED COMPUTER MODULE 
DEVICE INTERFACE MODULE 


EXTENDED COMPUTER MODULE 
DATA TYPE MODULE 
DATA STRUCTURE MODULE 
INPUT/OUTPUT MODULE 
COMPUTER STATE MODULE 
PARALLELISM CONTROL MODULE 
SEQUENCE CONTROL MODULE 
DIAGNOSTICS MODULE 
VIRTUAL MEMORY MODULE (HIDDEN) 
INTERRUPT HANDLER MODULE (HIDDEN) 

DEVICE INTERFACE MODULES 
AIR DATA COMPUTER 
ANGLE OF ATTACK SENSOR 
AUDIBLE SIGNAL DEVICE 
COMPUTER FAIL DEVICE 
DOPPLER RADAR SET 
FLIGHT INFORMATION DISPLAYS 
FORWARD LOOKING RADAR 
HEAD-UP DISPLAY 
INERTIAL MEASUREMENT SET 
PANEL 

PROJECTED MAP DISPLAY SET 

RADAR ALITIMETER 

SINS 

SLEW CONTROL 
SWITCH BANK 
TACAN 

VISUAL INDICATORS 
WAYPOINT INFORMATION SYSTEM 
WEAPON CHARACTERISTICS 
WEAPON RELEASE SYSTEM 
WEIGHT ON GEAR 


BEHAVIOR-HIDING MODULE DECOMPOSITION 
FUNCTION DRIVER MODULE 
SHARED SERVICES MODULE 


SOFTWARE DESIGN MODULE DECOMPOSITION 

APPLICATION DATA TYPE MODULE 

PHYSICAL MODEL MODULE 

DATA BANKER MODULE | 

SYSTEM GENERATION MODULE T 

SOFTWARE UTILITY MODULE “I 


r FUNCTION DRIVER MODULE 

AIR DATA COMPUTER FUNCTIONS 
AUDIBLE SIGNAL FUNCTIONS 
COMPUTER RADAR FUNCTIONS 
DOPPLER RADAR FUNCTIONS 
FLIGHT INFORMATION DISPLAY FUNCTIONS 
FORWARD LOOKING RADAR FUNCTIONS 
HEAD-UP DISPLAY FUNCTIONS 
INERTIAL MEASUREMENT SET FUNCTIONS 
PANEL FUNCTIONS 

PROJECTED MAP DISPLAY SET FUNCTIONS 
SINS FUNCTIONS 
VISUAL INDICATOR FUNCTIONS 
WEAPON RELEASE FUNCTIONS 
GROUND TEST FUNCTIONS 

-SHARED SERVICES MODULE 

MODE DETERMINATION MODULE 
STAGE DIRECTOR MODULE 
SHARED SUBROUTINE MODULE 
SYSTEM VALUE MODULE 
PANEL I/O SUPPORT MODULE 
DIAGNOSTIC I/O SUPPORT MODULE 
EVENT TAILORING MODULE 

APPLICATION DATA TYPE MODULE 

SYSTEM APPLICATION DATA TYPES 
LOCAL APPLICATION DATA TYPES 
SHARED APPLICATION DATA TYPES 


PHYSICAL MODEL MODULE 
EARTH MODEL MODULE 
AIRCRAFT MOTION MODULE 
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CHARACTERIZING FAMILIES 


By structure 

- module hierarchy, uses hierarchy, process structure 
By function 

- navigation, device control 
By application 

- avionics, satellite communications 
By technology 

- relational database, Monte Carlo simulation 

By ??? 

Families composed of modules 

Modules characterized by externally-visible behavior 

- Black-boxes 

- Abstract interfaces specify behavior 


SUMMARY 

Systematic Reuse Based on Families 
Concepts 

- Program Families (1976) 

- Information hiding (1970) 

- Abstraction 

- Behavioral specification (1972) 

- Hierarchies 

Examples 

- A-7 (1980) 

Relations to other technology 

- Ada 

- Object oriented programming 

- Object oriented design 



